Events - 1.51.0

A new tab has been added to the Payments Page, allowing users to configure the use of Allocating Unassigned Overpayments, giving control over Estate, Brand and individual Site usage of this feature:

Once this feature has been enabled, if overpayments are made to a booking, they can be reallocated. In the example below, £100 has been paid to the booking, but there are outstanding deposits that need to be fulfilled before the booking can be confirmed:

Clicking on the “Allocate Payments” button takes the user to the “Allocate Funds” screen, where money can be allocated to either the event or an individual attendee. By default, the lead guest can have funds allocated to them, however additional guests must be configured in the Guest Booking Portal before they will appear in this screen to be valid for allocating funds to:

Once the destination and amount have been selected, saving the page will apply these changes to the booking, giving a transaction success message:

The payments table on the booking screen will update:

The booking entry in Events Site Host is also updated with pills of the appropriate colour showing the balance of payments:

Occasions that are set up with recurrence patterns will now automatically have that logic applied to the Site Host Application, showing Site Hosts which days are valid for the selected Occasions. However, Site Hosts maintain the ability to override this functionality, and can confirm a booking for an invalid day should it be required. In the example below, this Occasion is configured for every other Monday, Wednesday, Friday and Sunday:

Once a booking has been assigned to a table in Tables, the information will be reflected in the Events Site Host Bookings Overview page:

This information will also be visible in the individual booking view on Events Site Host:

When making a Booking Rule, select the Condition as normal (e.g. Menu or Occasion etc.), and when setting the Actions, a user can now set it to be “Due after booking made”. The “Due after booking made” functionality requires the activity to be completed after the booking is made (e.g. due 1 day after booking on a Monday, requires the deposit paid on the Tuesday).

When a user attempts to delete a menu that has active bookings on, after the “Delete” button is pressed, a check is performed by the system.

If there are any future non-cancelled bookings that are linked to the selected menu, then a popup warning message will display and the delete request will be cancelled.

Email validation is now compliant with RFC 5336/7 standards across all aforementioned platforms. The validation only confirms that an email conforms to the validation standards, and does not check whether an account is actually valid.